home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / Oberon-FAQ / language < prev    next >
Text File  |  1994-04-08  |  11KB  |  285 lines

  1. Newsgroups: comp.lang.oberon,comp.answers,news.answers
  2. Path: bloom-beacon.mit.edu!hookup!news.kei.com!eff!usenet.ins.cwru.edu!agate!library.ucla.edu!psgrain!m2xenix!mikeg
  3. From: mikeg@psg.com (Mike Gallo)
  4. Subject: Comp.lang.oberon FAQ (monthly)
  5. Expires: Sun, 1 May 1994 07:00:00 GMT
  6. Reply-To: mikeg@psg.com
  7. Organization: PSGnet, Portland Oregon US
  8. Date: Fri, 8 Apr 1994 12:05:45 GMT
  9. Approved: news-answers-request@MIT.Edu
  10. Message-ID: <1994Apr8.120545.15151@psg.com>
  11. Followup-To: comp.lang.oberon
  12. Summary: This posting contains a list of Frequently Asked Questions
  13.     (and their answers) about Oberon.  It should be read by anyone
  14.     who wishes to post to the Comp.lang.oberon newsgroup.
  15. Lines: 267
  16. Xref: bloom-beacon.mit.edu comp.lang.oberon:1740 comp.answers:4821 news.answers:17827
  17.  
  18. Archive-name: Oberon-FAQ/language
  19.  
  20.      (*  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  *)
  21.  
  22.      Many FAQ lists, including this one, are available by anonymous
  23. ftp from rtfm.mit.edu in the /pub/usenet/news-answers directory.  
  24.      Thanks to all who have contributed!  Further additions,
  25. corrections, and suggestions are welcome.
  26.  
  27. mikeg@psg.com
  28.  
  29.      (*  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  *)
  30.  
  31. Comp.lang.oberon Frequently Asked Questions
  32. The Programming Language
  33.  
  34.  
  35. Copyright 1994 Michael Gallo
  36. (c) 1994 Michael Gallo
  37.  
  38.  
  39. THE PROGRAMMING LANGUAGE OBERON 
  40.  
  41. From "From Modula to Oberon"
  42.  
  43.           The programming language Oberon is the result of a
  44.      concentrated effort to increase the power of Modula-2 and
  45.      simultaneously to reduce its complexity. Several features were
  46.      eliminated, and a few were added in order to increase the
  47.      expressive power and flexibility of the language. This paper
  48.      describes and motivates the changes. The language is defined
  49.      in a concise report.
  50.           Whereas modern languages, such as Modula, support the
  51.      notion of extensibility in the procedural realm, the notion is
  52.      less well established in the domain of data types. In
  53.      particular, Modula does not allow the definition of new data
  54.      types as extensions of other, programmer-defined types in an
  55.      adequate manner. An additional feature was called for, thereby
  56.      giving rise to an extension of Modula.
  57.           . . . .
  58.           The evolution of a new language that is smaller, yet more
  59.      powerful than its ancestor is contrary to common practices and
  60.      trends, but has inestimable advantages. Apart from simpler
  61.      compilers, it results in a concise defining document, an
  62.      indispensable prerequisite for any tool that must serve in the
  63.      construction of sophisticated and reliable systems.
  64.  
  65.      Among the eliminations in the move from Modula-2 to Oberon are
  66. variant records, opaque types, enumeration types, subrange types,
  67. the basic type CARDINAL, local modules, and Modula's WITH
  68. statement.  The major addition to Oberon is the concept of type
  69. extension (i.e., single inheritance) for records.
  70.  
  71.  
  72. OBJECT ORIENTED PROGRAMMING IN OBERON
  73.  
  74.      Oberon does not offer multiple inheritance.  However, it has
  75. been shown that multiple inheritance can be efficiently implemented
  76. in terms of single inheritance and been argued that MI is therefore
  77. syntactic sugar that is rarely used in practice.  For details, see
  78. Templ (1993) and Mssenbck (1993).
  79.      Oberon does not offer built in "methods" as do many other
  80. languages supporting OOP.  Instead, conventional virtual methods
  81. can easily be implemented by a pointer to a procedure table, or
  82. "messages" can be sent to procedures as extensible records.
  83.      While some people complain about Oberon's minimalistic support
  84. of object oriented programming, others feel that this is one of
  85. Oberon's strengths, that the language does not institutionalize a
  86. particular approach to OOP (see the Comp.object FAQ list for an
  87. examination of several variations on the object oriented paradigm). 
  88. For another discussion, see Oberon2.OOP by H. Mssenbck.  
  89.  
  90.  
  91. THE PROGRAMMING LANGUAGE OBERON-2
  92.  
  93. From "Differences between Oberon and Oberon-2"
  94.  
  95.           Oberon-2 is a true extension of Oberon. . . .
  96.           One important goal for Oberon-2 was to make object-
  97.      oriented programming easier without sacrificing the conceptual
  98.      simplicity of Oberon. After three years of using Oberon and
  99.      its experimental offspring Object Oberon we merged our
  100.      experiences into a single refined version of Oberon.
  101.           The new features of Oberon-2 are type-bound procedures
  102.      [i.e., virtual methods], read-only export of variables and
  103.      record fields, open arrays as pointer base types, and a with
  104.      statement with variants. The for statement is reintroduced
  105.      after having been eliminated in the step from Modula-2 to
  106.      Oberon.
  107.  
  108.  
  109. THE "OBERON FAMILY" OF LANGUAGES
  110.  
  111.      Object Oberon is a now defunct, experimental extension of
  112. Oberon featuring "classes", structures somewhere between modules
  113. and records.  It evolved into Oberon-2.
  114.      Seneca was also an experimental extension of Oberon.  It
  115. focused on numerical programming on vector computer architectures. 
  116. It evolved into Oberon-V.
  117.      Oberon-V is an experimental dialect (but not a superset) of
  118. Oberon.  It is concerned with issues of numerical computing, array
  119. processing, and code verification.  It's primary new features are
  120. the ALL statement (a parallel version of the FOR loop) and array
  121. constructors for actual open array parameters.  Since it was
  122. originally aimed at vector architectures in general and the Cray Y-
  123. MP in particular, no Oberon-V compiler has yet been implemented for
  124. the Oberon System.  For details, see Griesemer (1993).
  125.  
  126.  
  127. COMMON PROBLEMS PROGRAMMING IN OBERON
  128.  
  129. The WITH statement
  130.  
  131. "This [compiler error] has to be a bug, correct me if I'm wrong!
  132. (I'm going nuts over this)"
  133.  
  134.      TYPE
  135.         Obj* = POINTER TO Empty;
  136.         Empty = RECORD (*nothing*) END;
  137.  
  138.         OpObj = POINTER TO OpNode;
  139.         OpNode = RECORD (Empty)
  140.            name : CHAR;
  141.            left, right : Obj;
  142.         END;
  143.  
  144.      PROCEDURE doeval(ex: Obj): REAL;
  145.      BEGIN
  146.         WITH ex : OpObj DO
  147.            CASE ex.name OF
  148.               "+" : RETURN doeval(ex.left) + doeval(ex.right);
  149.               (* clever code here *)
  150.            END;
  151.            (* more clever code here *)
  152.         END;
  153.      END doeval;
  154.  
  155. As thutt@clark.net (Taylor Hutt) points out,
  156.      . . . this is not a bug.  The WITH statement actually changes
  157.      the static type of the WITHed variable for the entire duration
  158.      of the WITH statement.
  159.           A workaround to this problem is to assign the parameter
  160.      to a temporary variable and to use the WITH on the temp.  A
  161.      type guard will not work properly in this case, do not attempt
  162.      to use it.
  163.  
  164.      Some people on Comp.lang.oberon think that because of its non-
  165. local effects, the WITH statement should be avoided entirely.  They
  166. point out that a programmer can use individual type guards or, if
  167. a guarded variable is used very many times, pass the variable to a
  168. procedure.
  169.  
  170.  
  171. BIBLIOGRAPHY
  172.  
  173.      Sources cited in the FAQ list that are not listed in the
  174. bibliography are electronically available in PostScript and/or
  175. Oberon text formats from ETH Zrich.  They can be acquired by
  176. anonymous ftp from:
  177.  
  178.      ftp.inf.ethz.ch:/Oberon,
  179.      wuarchive.wustl.edu:/languages/Oberon, and
  180.      gatekeeper@dec.com:/pub/plan/Oberon
  181.  
  182. "Type Extensions" by N. Wirth; ACM Transactions on Programming
  183. Languages and Systems; 10, 2 (April 1988) 204-214.
  184.  
  185. "From Modula to Oberon" by N. Wirth; Software: Practice and
  186. Experience; 18,7 (July 1988) 661-670.
  187.  
  188. "The Programming Language Oberon" by N. Wirth; Software: Practice
  189. and Experience; 18,7 (July 1988) 671-690.
  190.  
  191. "Variations on the Role of Module Interfaces" by J. Gutknecht;
  192. Structured Programming; 10,1 (January 1989) 40-46.
  193.  
  194. "Object Oberon -- A Modest Object-Oriented Language" by H.
  195. Mssenbck and J. Templ; Structured Programming; 10,4 (April 1989)
  196. 199-207.
  197.  
  198. A New Approach to Formal Language Definition and Its Application to
  199. Oberon by M. Odersky; Verlag der Fachvereine Zrich; 1989.
  200.  
  201. "The Programming Language Oberon-2" by H. Mssenbck and N. Wirth;
  202. Structured Programming; 12,4 (April 1991).
  203.  
  204. Programming in Oberon: Steps Beyond Pascal and Modula-2 by M.
  205. Reiser and N. Wirth; ACM Press; 1992.
  206.  
  207. "A Systematic Approach to Multiple Inheritance Implementation" by
  208. J. Templ; ACM SIGPLAN Notices; Volume 28, Number 4 (April 1993).
  209.  
  210. Object Oriented Programming in Oberon-2 by H. Mssenbck; Springer-
  211. Verlag; 1993.
  212.  
  213. A Programming Language for Vector Computers by R. Griesemer; Swiss
  214. Federal Institute of Technology (ETH Zrich); Dissertation Number
  215. 10277, 1993.
  216.  
  217.  
  218. OBERON COMPILERS
  219.  
  220.      Please note that mention of a product or company does not
  221. necessarily imply a recommendation.  For Oberon compilers developed
  222. outside ETH Zrich contact:
  223.  
  224. VAX/VMS:
  225.      ModulaWare GmbH, Wilhelmstr. 17A, D-91054 Erlangen/F.R.Germany
  226.           Modula-2 & Oberon-2 Compiler Manufactur
  227.           Tel. +49 (9131) 208395, Fax +49 (9131) 28205.
  228.           E-mail/Internet:
  229.                100023.2527@compuserve.com
  230.                g_dotzel@ame.nbg.sub.org
  231.  
  232. MS-DOS and Windows:
  233.      ModulaWare GmbH, Wilhelmstr. 17A, D-91054 Erlangen/F.R.Germany
  234.           OM2 32 Bit Oberon-2 and Modula-2 Compiler for PC/DOS
  235.           '386/'486 native code for DOS with DPMI Driver/Host and
  236.           for DOS sessions under Windows 3.1 and OS/2 2.1
  237.      COP2 (partial Oberon to C translator)
  238.           contact Taylor Hutt, e-mail: thutt@clark.net
  239.      Oberon-M
  240.           contact E. Videki, e-mail: erv@k2.everest.tandem.com
  241.      Extacy
  242.           Real Time Associates Ltd.
  243.           Canning House, 59 Canning Road
  244.           Croydon, Surrey, CRO 6QF
  245.           England
  246.           Tel.: 0044-81-656 7333
  247.           Fax: 0044-81-655 0401
  248.           E-mail: 71333.2346@compuserve.com
  249.                rta@rtal.demon.co.uk
  250.      Pow! (Programmers Oberon Workbench)
  251.           It works with Microsoft Windows and can be used to create
  252.           native Windows applications (EXE's and DLL's).
  253.           Ftp: ftp.fim.uni-linz.ac.at:/pub/soft/pow-oberon2, or
  254.           galileo.meakins.mcgill.ca:/Oberon/CommercialDemos/POW
  255.           E-mail: pow@fim.uni-linz.ac.at
  256.           Mailing list: majordomo@fim.uni-linz.ac.at "subscribe
  257.           pow-list"
  258.  
  259. Amiga:
  260.      A+L AG
  261.           Daederiz 61
  262.           CH-2540 Grenchen
  263.           Tel.: +41 (65) 52 03 11
  264.  
  265. DECstation (Ultrix, OSF/1), Intel386 (SVR4, OS2, Solaris), Sparc
  266. (Solaris):
  267.      Office of Commercial Services
  268.           Queensland University of Technology
  269.           GPO box 2434, Brisbane Q4001
  270.           Australia
  271.  
  272. Atari:
  273.      Martin Momberg
  274.           Hahlgartenstr. 13a
  275.           D-64331 Weiterstadt
  276.           Germany
  277.           E-Mail: Inet:momberg@dik.maschinenbau.th-darmstadt.de
  278.           Ftp: ftp.th-darmstadt.de:
  279.                /pub/machines/atari/programming/stoberon
  280. -- 
  281. A designer knows he has arrived at perfection not when there 
  282. is no longer anything to add, but when there is no longer 
  283. anything to take away.
  284.                 -- Antoine de Saint-Exupery
  285.